(1) Field of the Invention
The present invention relates to a terminal adapter for accommodating a data terminal device having an interface such as an RS-232C interface or the like in an ISDN (Integrated Services Digital Network), and more particularly to a terminal adapter capable of converting data between R-point asynchronous PPP and S/T-point multilink PPP.
(2) Description of the Related Art
The protocol of a data link layer, called Point-to-Point Protocol (PPP), is generally used for users to gain access to the Internet through a public network.
According to the PPP, only one logical link can be established with respect to one physical circuit. When, however, a protocol called multilink PPP is used, it is possible to regard a plurality of physical circuits (PPP links are established with respect to the respective physical circuits) as one logical link, logically enlarging a bandwidth.
Using the multilink PPP, two B channels of the ISDN may be regarded as one logical link to achieve an apparent transmission rate of 128 Kbps for faster access to the Internet.
In view of the above feature of the multilink PPP, it has heretofore been attempted to connect a data terminal device to a terminal of a terminal adapter with one physical circuit and also to connect two B channels of the ISDN to another terminal of the terminal adapter. The terminal adapter effects a protocol conversion between a PPP frame (not a multilink frame) from the data terminal device and a multilink PPP frame from the ISDN to realize faster access to the Internet.
The PPP and the multilink PPP have a negotiation function for using various options. When a link is established, a negotiation is carried out. In the negotiation, the type of an option to be used and the value of the option are carried in a Configure-Request-packet (hereinafter referred to as a "CR packet") to provide a request for using the option. If a party which has received the CR packet carrying the option which allows the option to be used, then the party returns a Configure-Acknowledge packet (hereinafter referred to as a "CA packet") which carries the same option type and option value. By following the above procedure, a PPP link is established including a setting for the user of the option.
There are available certain authentication protocols as such options for authenticating a party that has been connected. Among those authentication protocols are PAP (Password Authentication Protocol) and CHAP (Challenge-Handshake Authentication Protocol) which are finding frequent use in the art. According to the PAP, a party to be authenticated transmits an Authenticate-Request packet (hereinafter referred to as an "AR packet") which carries an ID and a password of its own in a text format to an authenticating party. If the authenticating party confirms that the party to be authenticated is permitted to use the link, then it transmits an A-ACK (Authenticate-Acknowledge) packet to the party to be authenticated. If the authenticating party cannot confirm that the party to be authenticated is permitted to use the link, then it transmits an A-NACK (Authenticate-Non-Acknowledge) packet to the party to be authenticated. Then, the authentication process of the PAP is finished.
According to the CHAP, an authenticating party transmits a challenge packet (hereinafter referred to as a "CHAL packet") which carries an ID and a challenge value of its own (hereinafter collectively referred to as an "encryption key") to a party to be authenticated. The challenge value is a random value which varies at all times. Having received the CHAL packet, the party to be authenticated encrypts its own password using the encryption key contained in the CHAL packet based on an MD5 algorithm, and transmits the encrypted password together with its own ID in a text format to the authenticating party.
The password encrypted on the basis of the MD5 algorithm cannot be restored to its original password. Therefore, the authenticating party searches a database for the password of the party to be authenticated based on the ID transmitted from the party to be authenticated, and encrypts the password with the encryption key that has previously been transmitted to the party to be authenticated. The authenticating party has the database which contains data about IDs and passwords of parties to be authenticated and also holds the encryption key that has previously been transmitted to the party to be authenticated.
If the password encrypted by the authenticating party agrees with the encrypted password transmitted from the party to be authenticated, then the authenticating party transmits a response packet (hereinafter referred to as a "RESP packet") which carries a success code representing an authentication success to the party to be authenticated. If the password encrypted by the authenticating party disagrees with the encrypted password transmitted from the party to be authenticated, then the authenticating party transmits a RESP packet which carries a failure code representing an authentication failure to the party to be authenticated.
For authenticating a party according to the multilink PPP, it is necessary to authenticate the party with respect to each physical link in a multilink system. For example, if two B channels (B1 channel and B2 channel) of the ISDN are put together as one logical link, then the party is authenticated with respect to the B1 channel and thereafter the party is authenticated with respect to the B2 channel. Such an authentication process will be described according to the PAP with reference to FIG. 6 of the accompanying drawings, and will be described according to the CHAP with reference to FIG. 7 of the accompanying drawings.
FIG. 6 shows a link establishing sequence and an authentication sequence according to the PAP. In FIG. 6, "DTE" represents a data terminal device, "TA" a terminal adapter, and "PEER" an ISDN device such as an access server. At an R point between the DTE and the TA, there is one physical link to which the asynchronous PPP is applied. At an S/T point between the TA and the PEER, there are two ISDN B channels to which the multilink PPP is applied. The ID and password of DTE to be authenticated are registered as being associated with each other in the PEER. The link establishing sequence and the authentication sequence shown in FIG. 6 will be described below with respect to successive steps.
[P21] Before this step, the B1 channel is called. Thereafter, the PEER sends a CR packet with the PAP indicated as an authentication protocol (AP) to the TA, providing a request to establish a link.
[P22] The TA transfers the CR packet to the DTE.
[P23] Since the establishment of a link is allowable and the use of the PAP is allowable, the DTE transmits a CA packet which carries the PAP to the TA.
[P24] The TA transfers the CA packet to the PEER.
[P25] The DTE sends an AR packet carrying its own ID and password to the TA, providing an authentication request.
[P26] The TA transmits the AR packet to the PEER, reads the ID and password contained in the AR packet and stores them in a memory.
[P27] The PEER compares the transmitted ID and password with registered IDs and passwords. If they agree, PEER transmits an A-ACK packet representing an authentication success to the TA.
[P28] The TA transfers the A-ACK packet to the DTE.
In this manner, the link establishing sequence and the authentication sequence for the B1 channel are completed. The steps [P21] through [P28] are carried out transparently between the PEER and the DTE.
[P29] Before this step, the B2 channel is called. Thereafter, the PEER sends a CR packet with the PAP indicated as an authentication protocol (AP) to the TA, providing a request to establish a link.
[P30] Since it is already known that the establishment of a link is allowable and the use of the PAP is allowable, the TA transmits a CA packet which carries the PAP to the PEER.
[P31] The TA reads the ID and password of the DTE from the memory, and transmits an AR packet carrying the ID and password to the PEER, providing an authentication request.
[P32] The PEER compares the transmitted ID and password with registered IDs and passwords. If they agree, the PEER transmits an A-ACK packet representing an authentication success to the TA.
In this manner, the link establishing sequence and the authentication sequence for the B2 channel are completed. The steps [P29] through [P32] are terminated at the TA.
FIG. 7 shows a link establishing sequence and an authentication sequence according to the CHAP. For authentication according to the CHAP, the ID and password of the DTE are registered beforehand in TA. The ID and password of the DTE to be authenticated are registered as being associated with each other in the database of the PEER. The link establishing sequence and the authentication sequence shown in FIG. 7 will be described below with respect to successive steps.
[P41] Before this step, the B1 channel is called. Thereafter, the PEER sends a CR packet with the CHAP indicated as an authentication protocol (AP) to the TA, providing a request to establish a link.
[P42] The TA converts the authentication protocol (AP) to "no authentication," and transfers the CR packet to the DTE. Since no authentication process is carried out between the TA and the DTE, the authentication protocol (AP) is converted to "no authentication."
[P43] Since the establishment of a link is allowable, the DTE transmits a CA packet carrying the authentication protocol (AP) representing "no authentication" to the TA.
[P44] The TA converts the authentication protocol (AP) back to the original CHAP, and transfers the CA packet to the PEER.
[P45] The PEER sends a CHAL packet carrying an encryption key to the TA, and holds the encryption key.
[P46] The TA extracts the encryption key from the transmitted CHAL packet, and reads the ID and password of the DTE which have been registered in advance. Based on the MD5 algorithm, the TA encrypts the read password of the DTE using the extracted encryption key. The TA transmits the CHAL packet carrying the encrypted password and the read ID in a text format to the PEER.
[P47] The PEER extracts the ID and encrypted password from the CHAL packet which has been transmitted thereto. The PEER then searches the database for a password corresponding to the extracted ID, and encrypts the located password using the encryption key that has been kept in the step [P45]. If the encrypted password agrees with the encrypted password transmitted from the TA, then the PEER transmits a RESP packet which carries a success code representing an authentication success to the TA.
The link establishing sequence and the authentication sequence for the B1 channel are now completed.
[P48] Before this step, the B2 channel is called. Thereafter, the PEER sends a CR packet with the CHAP indicated as an authentication protocol (AP) to the TA, providing a request to establish a link.
[P49] Since it is already known that the establishment of a link is allowable and the use of the CHAP is allowable, the TA transmits a CA packet which carries the CHAP to the PEER.
[P50] The PEER sends a CHAL packet carrying an encryption key Key* to the TA, and holds the encryption key Key*. The encryption key Key* which is carried on the CHAL packet in the step [P50] has a different challenge value, and hence has a value different from the encryption key which has been carried on the CHAL packet in the step [P45].
[P51] The TA extracts the encryption key Key* from the transmitted CHAL packet, and reads the ID and password of the DTE which have been registered in advance. Based on the MD5 algorithm, the TA encrypts the read password PW of the DTE using the extracted encryption key Key*. The TA transmits the CHAL packet carrying the encrypted password PW* and the read ID in a text format to the PEER.
[P52] The PEER extracts the ID and encrypted password PW* from the CHAL packet which has been transmitted thereto. The PEER then searches the database for a password corresponding to the extracted ID, and encrypts the located password using the encryption key Key* that has been kept in the step [P50]. If the encrypted password agrees with the encrypted password PW* transmitted from the TA, then the PEER transmits a RESP packet which carries a success code representing an authentication success to the TA.
The link establishing sequence and the authentication sequence for the B2 channel are now completed. The steps [P45] through [P52] are terminated at the TA.
In the authentication process according to the CHAP shown in FIG. 7, it is necessary to register the ID and password of the DTE in the TA. The reasons for registering the ID and password of the DTE in the TA will be described below.
If the DTE and the PEER were to communicate with each other transparently as according to the PAP shown in FIG. 6, the DTE encrypts its own password using the encryption key according to the MD5 algorithm, and transmits the encrypted password through the TA to the PEER. Inasmuch as the password, once encrypted according to the MD5 algorithm, cannot be restored to the original password, the TA is unable to recognize the password of the DTE from the encrypted password. Even if the TA kept the password of the DTE, the TA would fail to terminate the authentication sequence for the B2 channel in the same manner as with the PAP. The encrypted password kept in the authentication sequence for the B1 channel cannot be used in the authentication sequence for the B2 channel because the encryption key which the TA receives from the PEER in the authentication sequence for the B2 channel is different from the encryption key which the TA has received from the PEER in the authentication sequence for the B1 channel.
For the above reasons, it has been customary to register the ID and password of the DTE in the TA.
With the above process, however, if the DTE selectively uses a plurality of sets of IDs and passwords, then an ID and password registration procedure is complex to carry out.
Specifically, an application program (e.g., a PPP dialer) that can be installed in the DTE generally has a telephone book function capable of registering a plurality of different settings. Such an application program allows a plurality of sets of IDs and passwords to be registered. If the DTE contracts a plurality of Internet service providers, then the DTE can use different IDs and passwords for the respective Internet service providers. With the conventional authentication process according to the CHAP, however, it is necessary to register a set of ID and password in the TA, and each time the DTE changes its ID and password for connection to a different Internet service provider, a new set of ID and password has to be registered again in the TA. Therefore, the ID and password registration procedure is tedious and time-consuming to carry out.
Another problem is that because a set of ID and password is registered in the TA, there is a danger that the registered ID and password may possibly be stolen if the TA is carried away by an unauthorized person.